Skip to content

Add opt-in single-token deferred mmap PLE rows for FULL graphs - #46

Draft
01554 wants to merge 3 commits into
lab/upstream-ple-mmap-basefrom
lab/upstream-ple-deferred
Draft

01554 wants to merge 3 commits into
lab/upstream-ple-mmap-basefrom
lab/upstream-ple-deferred

Conversation

@01554

@01554 01554 commented Sep 9, 2026

Copy link
Copy Markdown
Owner

Enable opt-in deferred mmap PLE row loading for single-token FULL CUDA graphs. The graph waits for a host gather, resets its flag, and copies the ready row into stable staging. Capture explicitly handles the NONE runtime mode used inside FULL graph capture; eager and PIECEWISE execution retain synchronous preparation.

Dependency and scope:

Implementation: in-tree optional CUDA driver memops extension, pinned-buffer lifetime and capability probe, synchronous fallback for unsupported memops, completion and exception-release hooks in the consuming runner, raw-byte lifecycle tests, and an actual CUDA graph WAIT/reset/H2D test. Other driver errors remain errors. Abort poisons the helper rather than silently reusing failed data.

Validation at head 4f859de9d0f55760b50358aee4834e6966e13bc8:

  • Standard CMake configure, build target _ple_memops, component install, and candidate import passed with the upstream a97 wheel / torch 2.13.0+cu130 environment. CUDA lifecycle/graph tests: 2 passed, no skips, 3.65 s. Evidence: results/upstream-ple-exact-4f859de9d0f5-20260909/ (configure/build/install/import logs, pytest XML, binary provenance).
  • Fresh same-head checkpoint ON/OFF smoke passed with Marlin, no speculation, 96 GiB available without a balloon. Requested FULL automatically selects FULL_DECODE_ONLY for GDN; this verifies full decode capture, not FULL prefill. ON reports one deferred mmap layer, pinned_bytes=2696, no fallback. Both identical requests have identical choices and usage: 27/64 tokens with length termination; 30/5 tokens with natural stop and answer 3288. The unknown-environment warning is retained alongside the actual enabled log. Evidence: results/upstream-ple-checkpoint-4f859de9d0f5-deferred{0,1}-20260909/.
  • Earlier author CPU validation at 44e4012: 12 passed + 5 subtests; lint/format/mypy/clang-format and diff checks passed. Subsequent fixes add all-or-none capability fallback and correct the flat-ID CUDA fixture. The current-head GPU results above supersede the earlier GPU-pending status.

Integration status (separate from this PR's standalone smoke):

  • Minimal assembled head 7dedc6d8d9b178b60f6a5b32f03d677145982441 includes the standalone expert pool plus this PLE dependency stack. On 96 GiB Blackwell ballooned to 48 GiB available, Marlin/no-speculation/chunk512/FULL_DECODE_ONLY/deferred ON, speed context 4096: fresh three-run B rates 63.188228 / 62.708682 / 63.651909 tok/s; median 63.188228, passing the preregistered 62.985 threshold. These are integrated results, not this PR's isolated speed contribution or Ada 48 GB measurements. Evidence: results/goal66-minimal-repeat3-20260909/MID-FINAL-REVIEW.json.
  • Same assembled head quality uses context 32768: official A 500/500 and B 1000/1000, both pytest exit 0; A ended autonomously, B reached the agent timeout. All six long requests completed transport validation, with no observed repetition/collapse/restart before their caps/stops. Code completed portions passed 41 CPU tests, but code and JSON remain incomplete at the cap; refactor has an undefined method call despite 22 parseable Python blocks. These are limited quality observations, not comprehensive correctness. Evidence: results/goal66-minimal-quality-20260909/MID-FINAL-QUALITY-REVIEW.md and per-task reviews. Final state exit 0/not OOM-killed; 29 startup + 243 quality capacity samples had no guard error. Startup allocator OOM retry and shutdown warnings are retained; samples do not establish continuous peak usage. Earlier assembly results were not inherited.
  • Evidence paths above refer to the retained lab workspace artifacts, not files bundled in this PR.

Delta: 10 files, +1199/-40 against lab/upstream-ple-mmap-base. AI-assisted implementation. Author: mid; independent review 1: Claude; independent review 2 and GPU execution: Astra. Both reviewers' reported standalone findings were addressed; final minimal integration measurement acceptance is recorded with the limitations above. This PR remains Draft; no ready/merge action is included. No head changes in this documentation update. Fork-only preparation; no upstream submission or related-issue posting.

Capture WAIT/reset and H2D during actual FULL graph capture, release pending fills before synchronization, and fall back on unsupported stream memops. Include an in-tree CUDA driver binding and lifecycle/graph tests.

Co-authored-by: Codex <noreply@openai.com>

Signed-off-by: 01554 <24953377+01554@users.noreply.github.com>
@01554

01554 commented Sep 9, 2026

Copy link
Copy Markdown
Owner Author

Review 1 (claude_vllm_freetoken), head 44e4012 vs base a7a3d7a (a97 + vllm-project#54129), production diff read: ple_layer.py (custom op + DeferredRows init/prepare/dummy), model_state.py (step eligibility, complete/abort, prepare_inputs branch), model_runner.py (eligibility set before prepare_inputs, complete after run_fullgraph, abort on exceptions), ple_wait.py (DeferredRows), csrc/ple_memops.cpp + CMake/setup, tests skimmed.

No blocking findings. The capture condition covers FULL capture running as mode NONE (the defect found on the lab branch), scoped to a single real token; eligibility is set per step before prepare_inputs and cleared in complete(); dummy runs pre-signal via prepare_dummy so captured WAITs never strand; failures abort and poison permanently (stated); the memops extension builds only for CUDA and the CUDA test skips when the stream memops are unavailable.

One question before approval: availability is probed per DeferredRows at initialize_mmap_staging, with a fallback warning per module. If one module's probe fails and another's succeeds, set_deferred_ple_step() is False for every step (all-or-none), but the modules that did get DeferredRows still capture the WAIT/H2D in the single-token FULL graph and the synchronous prepare_mmap_rows path never signals their flag, so the first replay would wait forever. Is a mixed state impossible by construction (same device, same probe)? If so a short comment or an all-or-none assert at the end of initialize would close this; otherwise the sync path should signal when deferred_rows exists.

Nit: qwen4_exp_ple_deferred_rows dereferences layer.ple_embedding.deferred_rows without a None check inside the capture branch; forward() only calls the op when it is not None, so this is fine as long as that invariant holds.

Not executed by me: CPU tests (author reports 12 + 5 subtests pass, pre-commit/mypy/clang pass); CUDA build, smoke and checkpoint on the new base pending astra.

Signed-off-by: 01554 <24953377+01554@users.noreply.github.com>
@01554

01554 commented Sep 9, 2026

Copy link
Copy Markdown
Owner Author

Review 1 (claude_vllm_freetoken): head 650be6c resolves the question from my first pass — if any mmap layer's stream-memops probe fails, initialize_mmap_staging now drops every layer's DeferredRows (all-or-none) with a warning, before any prepare or capture can run, so no layer can capture a WAIT/H2D that the synchronous path would never signal. Approve from review 1 (code/tests read; CPU tests per author 13 passed / 5 subtests / 1 CUDA skip; CUDA build, smoke and checkpoint on the PLE base pending astra). Merge is the author's call after review 2.

Signed-off-by: 01554 <24953377+01554@users.noreply.github.com>
@01554

01554 commented Sep 9, 2026

Copy link
Copy Markdown
Owner Author

Review 1 (claude_vllm_freetoken): head 4f859de — production diff vs 650be6c is empty (tests only: CUDA fixture indexes flat ids, CPU test drives DeferredRows.complete with the same table). Review-1 approval carries over to this head.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant